Turnbull China Bikeride/Turnbull China Bikeride - Disc 2.iso/BARNET/ARMLINUX/MAIL/9707/[e-mail] _Wed Jul 2 23:46:52 1997.msg

Internet Message Format | 1997-11-30 | 4KB

Return-Path: <[e-mail]>
Received: from tulpi.interconnect.com.au ([e-mail] [192.189.54.18]) by odie.barnet.ac.uk (8.8.2/8.8.0) with ESMTP id XAA18902 for <[e-mail]>; Wed, 2 Jul 1997 23:46:50 +0100
Received: from ce (acc5-ppp51.mel.interconnect.com.au [210.8.0.179]) by tulpi.interconnect.com.au with SMTP id IAA20122
  (8.8.5/IDA-1.6); Thu, 3 Jul 1997 08:47:16 +1000 (EST)
Message-ID: <[e-mail]>
Date: Wed, 02 Jul 1997 20:45:44 +1000
From: Charles Esson <[e-mail]>
Organization: Colour Vision Systems
X-Mailer: Mozilla 3.0Gold (WinNT; I)
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail]
Subject: Re: Re ELF
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: RO

Matthew Wilcox wrote:
>
> > 1) Does anyone know where one gets the ELF standard.
>
> No.  Sorry.  Try a web search in altavista.
>

I have tried, I found out a lot about garden decoration. I remember
reading somewhere that the sunsite has it. I will try there ( and search
again).

> It isn't /that/ bad.  Other CPUs manage that, and considerably worse.  The
> problem is exacerbated by the RPCs slow memory bus, but it's still
> liveable with and it's considerably better than your alternative
> suggestion.
>
I think a lot of architectures cache after the MMU. The 68040, the only
other MMU I have spent time pondering, caches physical addresses.

Unfortunatly enginering is about trade offs. The biggest problem I see
is the stack space, this is a block of memory that can grow. If you have
a complete virtual address space for the task  you can place the stack
in the middle of a very large empty address space and let it do what it
wants. If all the tasks have to run in one vitual space there would have
to be some restriction.
But this would be better than being limited to the physical space ( see
OS9 as a unix derivative that does this). I can't see a reason to place
restrictions on a tasks size or the number of tasks. I can see there is
a risk that you would not be able to load a task because of memory
fragmentation, but I think this is in the same category as " You are
running out of paging file". An error you see and fix by closng a few
applications.

I think it's horses for courses. The strong Arms stength is low power,
and a core that flies.
It's disadvantages are, no FPU, cache controllers that work in the
virtual address space and to be honest bus bandwidth that makes the
cache controllers and write back buffer a must, if the core is going to
be kept busy ( no doubt I will find others as time goes on).

The strong arm is perfect for compute intensive real time work. I cannot
see it being the processor of choice for a general purpose PC. As much
as I dislike the intel instruction set
it would be a better choice for that application.

The instruction set is another reason to pick the ARM for real time
work, an irrelevent consideration if you are going to write everything
is C, if you are using the system for real time work there is a risk
that assembler will be used. The ARM has a really nice instruction set
and like the 68k I can see assembler code being a viable choice.

The marketing and the architecture of the ARM is aimed directly at the
real time market. There is a real need for a freely available real time
operating system. Perhaps it would be best if the linux ARM port made
trade offs that made it more suitable for the market the ARM is aimed
for.

One thing is for sure that is where my efforts will go, because this is
what I need.